Absolute privacy of the service in I2P: encrypted LeaseSet

The principle of I2P anonymity is the unknown location of the hidden service. Each hidden service (for example, a website or a user who visits it) interacts with other resources exclusively through anonymizing tunnels. Tunnels are built through the routers of network participants in the same way that other users build tunnels through our router. This model creates many direct connections between I2P routers, in which it is impossible to determine on which router a particular tunnel began or ended: thousands of simultaneous encrypted connections do not provide such an opportunity.

To contact any hidden service, you need to obtain its LeaseSet, which contains information about input tunnels and cryptographic keys. To do this, all server endpoints waiting for a connection publish their LeaseSets on floodfills - routers that act as a reference book or bulletin board. Despite the fact that floodfil receives only information about the first nodes of the input tunnels and cryptographic keys, i.e. There is no compromising information in the LeaseSet; the I2P architecture provides for the use of encrypted LeaseSets. This allows you to hide the presence of an endpoint (aka “hidden service” and “destination”) from possible monitoring on floodfills.

The unencrypted LeaseSet identifier is the usual intranet address of a hidden resource, only without the “.b32.i2p” ending. This allows holders of floodfills to see in clear form the addresses of resources that have been published with them. If you have raised a personal resource in I2P and do not want anyone else to accidentally find out about it, an encrypted LeaseSet is especially for you!

Hiding a LeaseSet identifier in English terminology is called blinding. This is where the name of the address of a hidden service with an encrypted LeaseSet comes from: “bb32” – blinded-b32. In turn, “b32” in all network domains is an abbreviation for the name of the base32 encoding, which encodes the information that makes up the domain. It's important to note that bb32 is just a term. In fact, this spelling is not used in addresses..

The LeaseSet identifier of type bb32 (which the floodfill sees) does not correlate with the address, so it cannot tell the floodfill owner the actual name of the resource published by him. Also, a short domain in the “i2p” zone cannot be attached to an address like bb32. The only way to access such a hidden service is to have its full address string. Receiving a bb32 address as input, the I2P router requests the corresponding encrypted LeaseSet from the floodfill, and then decrypts its contents using additional information encoded in the domain.

The domain name of a regular endpoint consists entirely of a hash of the full address (the set of cryptographic keys that then comes with the LeaseSet), and the encrypted LeaseSet address is the public signing key of the hidden resource, as well as three bytes of special information: flags, signature type, and type encrypted signature.

Familiarize yourself with the cryptographic details of blinding, i.e. hiding the LeaseSet identifier, as well as encrypting its contents, you can official document. According to the documentation provided, the encrypted LeaseSet supports two signature type: ED25519-SHA512 (type 7) and RED25519-SHA512 (type 11), however it is strongly recommended to use only the second one.

This is due to the fact that, firstly, signature type 11 is algorithmically more optimal for use in an encrypted LeaseSet, and secondly, signature type 7 is used by default and allows the unintentional use of an existing address in conjunction with an encrypted LeaseSet. Theoretically, this is a vulnerability because... allows an attacker floodfillr to reveal another encrypted LeaseSet of a service that previously used a regular LeaseSet with the same signature key. This is possible because of the blinding calculation algorithm, which can be replicated by knowing in advance the full endpoint address included in the LeaseSet. It is understood that a user who manually assigns signature type 11 will most likely immediately indicate the LeaseSet type he needs, which will prevent leakage.

The minimum configuration for a tunnel endpoint of type bb32 (which is sometimes called b33 for some reason, which does not have any logic) looks like this (the last two lines are important):

[SUPER-HIDDEN-SERVICE]
type = server
host = 127.0.0.1
port = 8080
inport = 80
keys = site.dat
signaturetype = 11
i2cp.leaseSetType = 5

Were mentioned a little earlier flags, the addresses containing the encrypted LeaseSet contained in the first byte. All that interests us in the context of this article is authorization flag. It is configurable via an additional configuration option i2cp.leaseSetAuthType. In short: this allows you to make access to a private resource even more controlled by creating a list of keys or passphrases for each user, and if something happens, remove a specific identifier from the list, after which the corresponding user will no longer receive a license, and therefore no access to the resource . You can find out more about this in article.